> It depends on where you want to draw the line between security and flexibility > (ie. do you want to be able to login as root from home and fix things up or > are you willing to have to come in an be physically at the console for those > - very rare - times when something has gone very wrong). Sure, I can think > of a number of scenarios when it is nice to be able to login as root via a > telnet session - but they are all times when there is a problem. We made the > decision a long time ago that we would bite the bullet in such situations and > give up the ease of logging in as root via a telnet session for the security > of only allowing root logins on the console - in our case the extra security > warrants it we feel. On certain machines (ie. a kerberos or other > authentication key server) I'd even recommend disabling the regular vendor > telnetd, rlogind, rshd, rexecd, rexd, etc. daemons in /etc/inetd.conf so that > your trusted security server machine doesn't become the first victim! > > If being able to get to the console and login as root at remote locations > (ie., you have isolated Unix boxes running a turnkey vertical application > out at branch offices or franchises where there are no sys admin staff) > is a real necessity I wouldn't recommend doing it via a public TCP/IP network - > I'd put the console (or auxiliary remote console) on a modem with several > levels of challenge on it - perhaps even a callback unit). > > As for the issue of allow root rlogin-without-a-password access via the /.rhosts > file so that your root passwords are not captured - there are two ways to > fix this problem. The first - as you say - is to use Kerberos or a similar > authentication system. The second is to build a more secure physical local > area network and enterprise (as much of it as you administer) network. This > can be done by getting rid of the shared LANs (primarily coax ethernet but > also a few other technologies/topologies) as much as possible and replaced > them with hubs providing private, bridged, switched connections (one machine > per port). Expensive but getting cheaper every day. These two steps > (and I would also recommend a firewall for most organizations connected to > the Internet) can make a network much more secure. Or you could just use encrypted telnet or my challenge responce system "Chalace". - Proff